1. Field of the Invention
This invention relates to management of software and data resources in a computing environment and more particularly relates to sharing and accessing data by scopes.
2. Description of the Related Art
Software technology continues to improve. With recent advances in the fields of web programming, data storage systems, personal computers and electronics, and computer networking, associated software programming is becoming more and more complex. One solution to help reduce the complexity of software programming is the adoption of object-oriented and component-based development methodologies. In object-oriented and component-based development a large software code is broken up into smaller objects, components and modules. These smaller portions of the code are self-contained in some instances, and used as building blocks to develop a larger software system. The smaller units are assembled, packaged and deployed to support the composition of multiplatform, multilayer, and multifunction system. Separate handling of software units creates additional complexity in sharing resources such as in-memory data as well as external objects among the deployment units.
FIG. 1 illustrates a common computing environment. Multiple software hosts or application servers, may be networked together to form a cluster. These clustered application servers may share application resources one to another. One application server may host multiple applications. Typically, an application is a composite of multiple modules, each module possibly containing multiple components. Applications are written in a modular format to simplify many aspects of software design. For example, if a developer breaks up an application into modules or components, he needs only to focus on one smaller portion of the application at a time. Another benefit of modularity is the ability to allow multiple developers to work on the application simultaneously.
One drawback of modular applications is the complexity of the final architecture. In some cases, a single application may include several layers of modules and components. For example, an application developed in Java 2 Enterprise Edition (J2EE) may include one or more modules. The modules can be Web modules, EJB modules, Client modules or Resource Adapter modules. Each module may include one or more components such as Servlets, JSP pages, Enterprise Java Beans (EJBs), and the like. Consequently, it becomes necessary to define the scope of each element of the computing system, and determine guidelines for sharing resources according to compatible scopes.
For example, in a J2EE environment, an application server may host an application containing two components in a module. A hit counter is required for each component to record the number of hits on the component. The counter object is shared among all the instances of that component and it is desirable that each component keeps its own counter object without interference from the other. A common implementation technique may keep the counter as a class variable (i.e., a static field of a java class or interface) of Counter class. If the Counter class is packaged in the application, the isolation can be broken and it turns out that the two components share the same counter. When the first component accesses the counter object, it may encounter unexpected values due to the modifications made to shared variable by the second component.
In another example, multiple objects may need to share information between the objects. However, in J2EE a separate class loader may load each object. If the variable that needs to be shared is declared static or local, each instance of the object may only locally modify the variable. For example, two separate web applications may request access to a hit counter object, and specifically to the counter variable of the hit counter object. The web applications need to increment the same hit counter for. If two separate class loaders load the hit counter class, and the counter variable of the hit counter object is declared static, the applications may increment the counter variable of the local instance of the hit counter object, but not share access to the counter variable with the other web object.
In another example, software activity based scoping issues may arise. These may be considered horizontal scoping issues, because the typical hierarchical structure does not apply. For example, an activity, a thread, a transaction, an Hypertext Transfer Protocol (HTTP) session, or the like are considered to by activity oriented. An HTTP session may be created to handle certain web activities. However, some activities may require separate HTTP sessions. If a web application performs certain activities on a web page, but a user requests the application to perform activities that require a new web page, an new HTTP session may be required. In this situation, horizontal scoping is required.
The problems highlighted in the examples above may be amplified in the J2EE environment. Unlike its predecessor Java 2 Standard Edition (J2SE), J2EE utilizes multiple class loaders to access software resources. One application, module, or other component may access a shared resource with its class loader, while a second class loader accesses the same shared resource (i.e., the global variable of the scoped singleton). The first component may not have information regarding actions taken by the second component on the shared resource. Alternatively, two parent objects may desire shared access to a variable, but only get local access to the variable because the J2EE class loaders have created separate instances of the object and associated static or local resource. Therefore, the first and the second components may encounter errors or unexpected results because an object may include static attributes shared between multiple instances of the object.
As a workaround in J2EE, some scoping between objects may be achieved by careful deployment, packaging, and class loader delegation. Scoped deployment includes limiting object deployment to a predefined hierarchical order. For example, if a class variable is to be shared by multiple applications running on the same JVM, the class has to be deployed to the class path of an ancestor class loader of all the application class loaders.
To support the packaging and deployment model, a J2EE server typically uses a hierarchy of class loaders to load classes from different deployment units. The classes used by an application can be loaded by different class loaders in the hierarchy. This aspect of J2EE creates visibility issues at java class level for sharing information among components across deployment units. The class loader delegation model creates scopes for sharing and isolation, however the developers must predetermine the delegation architecture. Such a task may be inordinately time consuming, and intellectually challenging. Typical developers of ordinary skill in the art are not concerned with the intricacies associated with class loader delegation.
Unfortunately, implementation of effective scoping in complicated applications may be difficult or even impossible. Currently two options for scoping exist. Either the developer must define, package, and properly deploy separate instances of each resource to be used within a different scope relying on the class loader hierarchy and delegation model, or implement a custom designed set of objects and methods to associate scope with instantiated objects.
These custom designed solutions tend to be particularly suited to a scoping scheme specific to the scoping problems faced by a developer. Another difficulty associated with the scoping solutions described above is the limited application of each solution. The solutions typically are specific to a single scoping goal. Therefore, the scoping solutions may not apply to every situation in which software object scoping is desirable. It would be useful to provide a scoping framework broad enough to apply to a wide variety of development and runtime applications. Additionally, it would be useful to provide flexible customization of scoping as a plug-in feature of the framework.
From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method that provide scoped management for software objects. Beneficially, such an apparatus, system, and method would reduce scope related errors, simplify scoped data sharing and access by providing a broadly applicable, and highly flexible scoping service.